Columbia Kermit/kermit.zip/newsgroups/misc.19960715-19961006/[e-mail] _Sat Jul 27 11:42:39 1996.msg

Internet Message Format | 2020-01-01 | 6KB

Return-Path: [e-mail]
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id LAA21529 for <[e-mail]>; Sat, 27 Jul 1996 11:42:39 -0400 (EDT)
Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id LAA17278 for kermit.misc@watsun; Sat, 27 Jul 1996 11:42:38 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
Date: 27 Jul 1996 15:42:17 GMT
Organization: Columbia University
Lines: 91
Message-ID: <4tddcp$[e-mail]>
References: <[e-mail]> <4t63nh$[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:5658 comp.dcom.modems:145804

In article <[e-mail]>,
Charles Roten <[e-mail]> wrote:
: In article <[e-mail]> [e-mail]
: (Charles Roten) wrote:
: >
: >set dial speed-matching off    <<<<---    _This_ line was _just_ _now_ added,
: >                       and _has_ _not_ _been_ _tested_
: >                       _yet_.  If it works .. thanks,
: >                       Clarence.
:  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
:
: ** BAD IDEA !!! **  I just A/B'ed this line with a test with the line
: commented _out_.  Results below.
:
Please read the documentation.  What does "set dial speed-matching" do?
It merely tells C-Kermit whether to adjust its interface speed to match the
speed reported in the modem's CONNECT message.  Either it does or it doesn't.
One way is right, one way is wrong.  If you pick the wrong way, the connection
will be totally unusable because the interface speed of the modem and the
computer will be different.

: I just tried to download a mail archive of uuencoded stuff with two versions
: of the above .kermrc file.  Archive size was 2280872 bytes.
:
If you were able to log in to the remote host, then the interface speed was
right.  So whatever "set dial speed-matching" value you had in effect when you
did this was correct.

: _With_ 'set dial speed-matching off', I got the following:
: 1) _Lousy_ average packet sizes, all over the map but rarely at the
:    practical maximum of 8999 bytes.
: 2) _Lousy_ throughput .. around 1200 CPS.
: 3) Premature termination due to multiple timeouts less than a quarter of
:    the way through the download.
:
: _With_OUT_ this "feature" enabled, I got a successful transfer with an
: effective data rate of 2149 CPS.
:
You are using a modem which might or might not have error correction and
compression built in.  Read the Kermit FAQ about the implications of this.
If you have an RPI modem, ALL BETS ARE OFF.  NOTHING, repeat NOTHING, can be
expected to work right, NOT EVEN FLOW CONTROL, because flow control depends
on having a modem-to-modem protocol, which will not happen when trying to
use an RPI modem on UNIX.

Second: You are going through an intermediate TELNET program.  Think about
this.  Think about the additional overhead it introduces.

: In conclusion .. "set dial speed-matching off" makes things WORSE .. a LOT
: worse.
:
No, there is something else going on.  "set dial speed-matching" has nothing
to do with it.  If you get good transfers sometimes and poor ones other times,
it is due to some other factor.

Let's assume your modem is NOT an RPI model, since if it were, you would
probably NEVER get decent performance out of it.  Then what would account for
getting good performance sometimes but not others, with all else being equal;
i.e. using the same Kermit settings.  The answer: obviously it is something
external to your Sun.  Here are just a few possibilities:

 1. An error-corrected connection was not negotiated, and so therefore
    flow control is not effective, but you are blasting 9000-byte packets
    into the modem.  A recipe for disaster.  How could this happen?  Maybe
    some of the modems at your ISP are badly configured.  This is a very
    common occurrence -- in large modem pools, modems frequently lose their
    configurations, and require constant monitoring and attention.  To
    check, escape back to your modem (plus-plus-plus) and give an ATI6 (or
    whatever) command to see its current protocols, speed, etc, if your
    modem offers such a command.

 2. Maybe your ISP is using a mixed bag of terminal servers.  Some terminal
    servers (such as Cisco ASM models) do not support hardware flow-control
    in the upstream direction, so uploads almost always fail.  It's the luck
    of the draw which terminal server your call hunts to.  Check with your
    ISP.

 3. A lack of effective flow control between C-Kermit on the Sun and your
    modem.  Your C-Kermit initialization file does say "set flow rts/cts",
    but how do you know your modem is configured for that also?

The next release of C-Kermit, 6.0, simplifies all of this to a great extent.
It now incorporates a database of modems, and ensures that the modem is
configured according to C-Kermit's own settings.  For example, if you tell
C-Kermit to "set flow rts/cts", it will issue the modem-specific command to
ensure that the modem, too, is configured for RTS/CTS.  C-Kermit 6.0 is
presently in Beta test.  See the Kermit Web page for further information:

  http://www.columbia.edu/kermit/

- Frank